InfoMagic Internet Tools 1993 July/Internet Tools.iso/RockRidge/mail/pine/imap_archive/text0024.txt

Text File | 1993-07-02 | 17.3 KB | 336 lines

>> One such extreme view -- which I subscribe to -- is that the privacy
   violation of this sort of function is of greater concern than the benefits.

I too agree with this point of view.

Bill

-------
From [e-mail]  Tue Sep 29 02:37:26 1992
Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu
    (5.65/UW-NDC Revision: 2.27 ) id AA19704; Tue, 29 Sep 92 02:37:26 -0700
Received: by mx1.cac.washington.edu
    (5.65/UW-NDC Revision: 2.27 ) id AA15194; Tue, 29 Sep 92 02:37:19 -0700
Errors-To: [e-mail]
Sender: [e-mail]
Received: from snow.csi.cam.ac.uk by mx1.cac.washington.edu
    (5.65/UW-NDC Revision: 2.27 ) id AA15188; Tue, 29 Sep 92 02:37:17 -0700
Received: from phx.cam.ac.uk by ppsw1.cam.ac.uk
          with NIFTP (PP-6.0) as ppsw.cam.ac.uk id <[e-mail]>;
          Tue, 29 Sep 1992 10:37:01 +0100
Date: Tue, 29 Sep 92 10:36:49 BST
From: A Grant <[e-mail]>
To: [e-mail]
Subject: Re: Re: Some general mail message issues
Message-Id: <[e-mail]>
In-Reply-To: <[e-mail]>

> One such extreme view -- which I subscribe to -- is that the privacy
> violation of this sort of function is of greater concern than the
> benefits.  I do not necessarily want to acknowledge certain messages,
> much less tell someone if and when I read it.

'finger' is a violation of privacy. Yet the way that this has been dealt
with is not to suppress the protocol, but to make running a finger daemon
optional. Many people still run it though.

Let's distinguish between

- delivery to the user's message store, which should happen within a
  matter of minutes. For inter-domain (e.g. international) mail it is
  particularly useful to know if the mail is getting to the destination
  domain ok, i.e. that (say) transatlantic links aren't broken, or that
  gateways have been crossed successfully. (Incidentally, there is scope
  here for delivery reports containing information about conversions
  that have taken place between multimedia formats.)

- read acknowledgement, which is much more vague, and relies on the MUA
  trying to guess when the user has read the message. Do they have to
  read to the end? If it's a MIME message with a multimedia components,
  do they have to view all components? What if, simply, it's in a language
  they can't read? This is a much trickier problem, and is balanced by the
  fact that read-acks are of less use to senders, or to postmasters at
  sending sites, because of the possibly long wait times involved.

> One frightening thought is the prospect of service of
> legal process through e-mail.

Process serving requires delivery of (a hard copy of) the message into
the user's own hands (possibly with the assistance of a couple of heavies),
not into their 'message store'. Even with read-ack as opposed to
delivery-ack, it's unlikely that legal process could be served in
electronic form, since the recipient could always claim that "I hit the
wrong key and deleted the message before I'd read all of it".

In contrast, nobody claims that registered mail is a privacy violation.
If I send a valuable package to a company, I'd like to know when it has
entered their sorting office. If I send important e-mail to an employee,
I might like to know when it has entered the company's mail domain.

> The possibility also exists of covert channels;
> remember, you can get more information out of an acknowledgement than
> just the fact that the message was received.

Delivery-acks (of the form "message <message-id> has entered domain <prmd>"
doesn't have to tell you anything, such as what are valid mail addresses,
or attributes of the message store such as its time zone or operating
system, that you can't deduce from a fail report. Spooks don't generate
fail reports, so they hardly fit into a general discussion of mail
protocols.

In an academic context there is no reason (other than a very slight
increase in traffic) for not allowing senders to request read-ack.
And in _any_ context there is no reason for not allowing them to request
delivery-ack. And if I was running a mail switch, which I'm not, I would
see no reason for it not to give delivery-acks to people who wanted them.
Read-acks are, as you say, for the recipient to decide, but personally I'm
doubtful of the motivation of someone who pretends not to have read a
message.

So I'd say make it part of the protocol, then leave it for system admin
to disable the feature if they want, just as they disable finger daemons.

Of course, delivery reports and read-acknowledgements have to be
unforgeable, but that's another story!

p.s. the EDI world has had some interesting thoughts about this sort of
thing, and since EDI is moving towards being based on top of mail, there
might be useful precedents there. In particular, the legal implications
have probably been explored at great length!
--
Alasdair Grant                                    [e-mail]
MVS Systems Group / Small Systems Integration Group      [phone]
University Computing Service, Pembroke St., Cambridge CB2 3QG, UK
From [e-mail]  Tue Sep 29 04:28:15 1992
Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu
    (5.65/UW-NDC Revision: 2.27 ) id AA21005; Tue, 29 Sep 92 04:28:15 -0700
Received: by mx1.cac.washington.edu
    (5.65/UW-NDC Revision: 2.27 ) id AA15981; Tue, 29 Sep 92 04:28:11 -0700
Errors-To: [e-mail]
Sender: [e-mail]
Received: from snow.csi.cam.ac.uk by mx1.cac.washington.edu
    (5.65/UW-NDC Revision: 2.27 ) id AA15975; Tue, 29 Sep 92 04:28:06 -0700
Received: from phx.cam.ac.uk by ppsw1.cam.ac.uk
          with NIFTP (PP-6.0) as ppsw.cam.ac.uk id <[e-mail]>;
          Tue, 29 Sep 1992 12:27:39 +0100
Date: Tue, 29 Sep 92 12:27:30 BST
From: A Grant <[e-mail]>
To: [e-mail]
Subject: Re: [CMU functional requirements document]
Message-Id: <[e-mail]>
In-Reply-To: <[e-mail]>

Very interesting... could you say who is defining this protocol, e.g. IETF,
international, or proprietary to CMU and released on an as-is basis?

Although it talks about (and virtually dismisses - have you participated in
X.400(92), then?) "support for X.400", it doesn't mention convergence with
protocols such as P7, _or with the set of functions provided by them_, even
if differently (e.g. textually rather than BER). With similar protocols,
one could have a common MUA front end with back ends for ASN.1-over-OSI
(a la P7), text-over-TCP (a la IMAP2) etc. As I said before, the effort
these days is not in designing protocols, but in getting MUAs to work with
half a dozen different GUIs, not to mention 100 different PC video cards.
Look at how long it's taking to port Pine to MS-DOS. (The implication that
this is due to the cussedness of the platform is meant as a compliment!)

After all, _you_ may see IP mail protocols as a DARPA or Andrew thing,
but I see them as a stopgap until X.400 is widely available on PCs.
It would be a real bonus if the work that had gone into remote-management
MUAs could transfer neatly to OSI. Could you perhaps tell us how likely
this is?

p.s. if you think X.400 has flaws, do something! The USA has far more
influence on ISO and CCITT than the rest of the world has on the IETF.
From [e-mail]  Tue Sep 29 12:03:08 1992
Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu
    (5.65/UW-NDC Revision: 2.27 ) id AA28786; Tue, 29 Sep 92 12:03:08 -0700
Received: by mx1.cac.washington.edu
    (5.65/UW-NDC Revision: 2.27 ) id AA20374; Tue, 29 Sep 92 12:03:01 -0700
Errors-To: [e-mail]
Sender: [e-mail]
Received: from PO5.ANDREW.CMU.EDU by mx1.cac.washington.edu
    (5.65/UW-NDC Revision: 2.27 ) id AA20368; Tue, 29 Sep 92 12:02:58 -0700
Received: by po5.andrew.cmu.edu (5.54/3.15) id <AA18107> for [e-mail]; Tue, 29 Sep 92 15:02:50 EDT
Received: via switchmail; Tue, 29 Sep 1992 15:02:47 -0400 (EDT)
Received: from nifty.andrew.cmu.edu via qmail
          ID </afs/andrew.cmu.edu/service/mailqs/testq0/QF.Eem:TY200WA7RFbk5N>;
          Tue, 29 Sep 1992 15:00:52 -0400 (EDT)
Received: via niftymail; Tue, 29 Sep 1992 15:00:45 -0400 (EDT)
Date: Tue, 29 Sep 1992 15:00:42 -0400 (EDT)
From: Chris Newman <[e-mail]>
Subject: Re: Re: Some general mail message issues
To: [e-mail]
In-Reply-To: <Pine.3.03.9209281244.A14112-b100000@isasun-3>
References: <Pine.3.03.9209281244.A14112-b100000@isasun-3>
Message-Id: <[e-mail]>

On Mon, 28 Sep 1992, David Herron wrote:
> Is the way these message-store-ish things are implemented an issue?  In our
> product the UA fiddles directly with a PP-style ".mailfilter" file (our
> MTA is based on PP) in order to configure these kind of services.
Well, this depends on how sophisticated delivery filtering you want &
such. A message management protocol could simply support shipping an
implementation defined "filter program" to the mailstore which could
be used by zmail or whatever other filing system might be there.  If
you want a nice MUA interface to the filtering/etc (at least for simple
tasks), the message-store-ish implementation may become an issue.

 Steve Hole <[e-mail]> writes:
>One thing that I do not like about the current run of MTA's and MUA's is that
>they all depend on host based authentication and configuration.  I don't think
>that it should be necessary for a user to have an account on the host that the
>message store resides on to hold configuration information for the
>MUA or MTA. Would it not be far better for this type of information
>to be held either in the message store, or (better) a distributed
>network service?
The kerberos additions to IMAP2bis should give one solution to the
host-based authentication problem.

>1.  What types of things will the mail management protocol manage?
>    What will be its mandate?
>
>    To me it (1) must be able to manage folders (manage the message
>    store), and (2) configure message services like those that we have
>    talked about.   Is this correct - is there more?
We're thinking about the message management protocol as being a step
up from where you're thinking.  In a large site (like CMU), a single
IMAP server will not suffice.  We need multiple IMAP servers and a
seemless way to find the right ones.  Here's some issues that could be
addressed by a message/folder management protocol:

1) Finding the IMAP server on which a folder resides.
2) Keep/update global user subscription & reading information.
3) Provide a "master update service" which can list all
folders/bboards with new messages since user last read.
4) Folder management including moving folders between IMAP servers and
possibly even replication of folders.
5) Anything else which doesn't fit in one of the other protocols:
    authentication (Kerberos), mailstore access (IMAP),
    mail submission (SMTP), user directory service (?)
   This will probably include some of the configuration options we've
   been discussing.

>2.  Where will the static user configuration information reside?  In
>    some sort of directory service?
Yes.  Either in the user directory service if there is a good enough
one out there, or in a directory service managed by the message
management protocol.

        - Chris
From [e-mail]  Wed Sep 30 06:33:20 1992
Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu
    (5.65/UW-NDC Revision: 2.27 ) id AA16312; Wed, 30 Sep 92 06:33:20 -0700
Received: by mx1.cac.washington.edu
    (5.65/UW-NDC Revision: 2.27 ) id AA29192; Wed, 30 Sep 92 06:33:04 -0700
Errors-To: [e-mail]
Sender: [e-mail]
Received: from nexus.yorku.ca by mx1.cac.washington.edu
    (5.65/UW-NDC Revision: 2.27 ) id AA29186; Wed, 30 Sep 92 06:33:01 -0700
Received: from localhost ([127.0.0.1]) by nexus.yorku.ca with SMTP id <9231>; Wed, 30 Sep 1992 09:32:51 -0400
To: [e-mail]
Cc: Chris Newman <[e-mail]>
Subject: Re: Some general mail message issues
Date:     Wed, 30 Sep 1992 09:32:38 -0400
From: [e-mail]
Message-Id: <[e-mail]>

On Mon, 28 Sep 1992, David Herron wrote:
| > Is the way these message-store-ish things are implemented an issue?  In our
| > product the UA fiddles directly with a PP-style ".mailfilter" file (our
| > MTA is based on PP) in order to configure these kind of services.

In   <[e-mail]>  you write:
| Well, this depends on how sophisticated delivery filtering you want &
| such. A message management protocol could simply support shipping an
| implementation defined "filter program" to the mailstore which could
| be used by zmail or whatever other filing system might be there.  If
| you want a nice MUA interface to the filtering/etc (at least for simple
| tasks), the message-store-ish implementation may become an issue.

  If you expect this to fly, you'd need to at least define and register as
set of well-known filters, and it would be up the the MUA and message-store
people to agree on the semantics of each, plus their extension mechanism
for not-well-known filters.
  This is easy if you're writing an ``integrated package'', but once you
drop the one-world assumption and start worrying about interoperability in a
hetrogenous world, it gets real complex real fast.

  I think this is **another** kind of a split user agent and not a
message-store, at least not in the x.400 sense of message-store.

  A carefull analyis of what can best be done where is advised. This
isn't something with a simple, elegant answer: it is trivial to
tell a mta or message-store ``I've moved to xxx@yyy''. It's tricky
to tell it ``filter my mail into categories a and b by forwarding a to
XXX'', and its bloody hard to tell it to apply more complex rules unless
both ends of the conversation agree to a fine level of deatil about what
each and every word of the instuctions means.

  I only recommend such where both ends of the conversation are
strictly controlled by the same development/specification group, and where
the requirements on implementers **not** proposing to implement such
a scheme are minimal.  Ie, if it isn't part of the official protocol.
  This is a reasonable, marketable approach to adding common functionality
in a non-decomposable commercial product. It isn't something I'd like
to standardize until I saw some different, interworkable, implementations.


--dave
[Ie, I wouldn't spend budgeted time on implementing it for us, but
 might buy a product that promised to do it in a way that wouldn't
 affect our existing multi-brand, multi-protocol, multi-religion site.
 I can't afford to maintain one-offs.]
From [e-mail]  Tue Oct  6 10:35:21 1992
Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu
    (5.65/UW-NDC Revision: 2.27 ) id AA24965; Tue, 6 Oct 92 10:35:21 -0700
Received: by mx1.cac.washington.edu
    (5.65/UW-NDC Revision: 2.27 ) id AA06301; Tue, 6 Oct 92 10:34:59 -0700
Errors-To: [e-mail]
Sender: [e-mail]
Received: from CAMIS.Stanford.EDU by mx1.cac.washington.edu
    (5.65/UW-NDC Revision: 2.27 ) id AA06293; Tue, 6 Oct 92 10:34:57 -0700
Received: from msob-a-fp-dynamic.Stanford.EDU by CAMIS.Stanford.EDU (4.1/inc-1.0)
    id AA04842; Tue, 6 Oct 92 10:34:40 PDT
Date: Tue, 6 October 1992 10:46:28 -0800
From: Adam Treister <[e-mail]>
To: A Grant <[e-mail]>
Subject: Re: Read Acknowledgement
Cc: [e-mail]
Message-Id: <[e-mail]>
In-Reply-To: Your message <[e-mail]> of Tue,
 29 Sep 92 10:36:49 BST
Content-Type: TEXT/plain; charset=US-ASCII

I happen to be in favor of read and delivery acks, and am planning on adding
request-read-ack and read-ack to Mailstrom.  I can't really see what skeletons
will come out of MY closets based on the time I read mail, tho I'd be interested
in hypothetical cases where this would be a issue.  And considering that any
self-respecting hacker can probably get at the contents of my mailbox, this is a
relatively minor breech of security. (IMHO)  And if it is, isn't timestamping
sent messages likewise invasive?

I am even tempted to take a hard line approach and not allow the user to read it
without acknowledging, but for now I'll put the switch in, and decide later if
I'll give an interface for setting/clearing it.

My question:  Is there an accepted standard header that's used for this purpose,
or should I create a X-Read-Acknowledge, which would effectively mean that
Mailstrom users would only acknowledge mail to other Mailstrom users?

Maybe RSVP is a kinder and gentler approach, whereby the reader automatically
creates a reply with a timestamp and sufficient text to indicate that the
message has been read, but allows the reader to append a reply (or edit the text
or throw away the reply).  Until the feature becomes required, it really has no
teeth, as users can refuse to read the message, and go to a non-enforcing mailer
to read that message, so the soft approach may be best for now.  But a standard
header that allowed Delivery Ack, Read Ack, or RSVP would be nice in the next
822 revision.  I would assume X.400 includes this (what doesn't it include?)
What variations does it have?

------------------------------
Adam Treister
415-508-9349
[e-mail]